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ABSTRACT 


The  Administrative  Sciences  (AS)  Department  of  the  Naval  Postgraduate  School  (NPS)  produces 
a  high  volume  of  travel  orders  for  both  civilian  and  military  personnel.  The  data  used  in  these 
documents  consist  of  all  departmental  personnel  and  travel  data.  This  database  requires  constant 
and  labor  intensive  maintenance  to  ensure  accurate,  up-to-date  personnel  and  travel  information. 
This  thesis  defines,  designs  and  implements  a  database  application  that  the  Administrative 
Sciences  Department  can  use  to  manage  the  departmental  travel  order  and  travel  claims 
requirements.  This  new  prototype  is  named  "Travel  Database  System  (TDS)",  version  1.0.  This 
document  provides  an  in  depth  outline  covering  software  requirements  analysis,  design  and 
implementation.  This  system  was  written  using  OMNIS7  Integrated  Development 
Environment,  version  1.03.  OMNIS7  is  a  Microsoft  Windows  based  application  generator. 
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I.  INTRODUCTION 


A.  OBJECTIVE 

The  purpose  of  this  thesis  is  to  design  and  implement  a  Microsoft  Windows-based 
database  system.  This  will  significantly  decrease  the  labor  hours  consumed  in  the 
generation  of  travel  orders  and  travel  claims  within  the  Administrative  Sciences 
Department  at  the  Naval  Postgraduate  School.  The  manual  system  currently  in  place  will 
be  replaced  by  a  single  point  data  entry  system  in  which  repetitive  tasks  will  be 
automated  to  the  greatest  extent  possible.  The  practice  of  reentering  data  for  each  travel 
order  and  travel  claim  will  be  eliminated.  The  system  will  produce  computerized  reports 
which  meet  external  reporting  requirements  while  providing  the  ability  to  generate 
custom  internal  reports  on  an  ad-hoc  basis.  The  Microsoft  Windows-based  system  will 
require  minimal  computer  knowledge  by  the  end-user.  The  application  is  written  using 
OMNIS7  Integrated  Development  Environment  and  is  implemented  on  a  Microsoft 
Windows-based  personal  computer. 

Travel  Database  System  is  a  Windows  based  application  that  allows  the  travel  clerk 
to  enter  a  complete  record  through  the  entry  of  multiple  data  fields  in  related  windows. 
The  application  provides  a  method  for  retrieving,  editing,  deleting,  inserting  records.  The 
system  is  tailored  to  produce  the  DD  1610,  NAVPERS  1320  and  the  DD  1351. 
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B.  TRAVEL  DATABASE  SYSTEM:  AN  OVERVIEW 

The  Travel  Database  System  (TDS)  is  developed  to  enhance  me  ability  of  the 
Administrative  Science^  Department  to  automate  the  generation  of  travel  orders  and 
travel  claims  for  both  civilian  and  military  personnel.  To  accomplish  this  goal  a  detailed 
analysis  of  the  required  input  forms  and  output  reports  was  conducted.  From  this  the 
flow  of  information  as  well  as  the  unique  attributes  associated  with  each  was  determined. 
The  DD  1610,  NAVPERS  1320  and  the  DD  1351  forms  were  used  as  the  basis  for  the 
initial  data  structure.  User  requirements  were  determined  through  extensive  interviews. 
The  requirements  were  transformed  into  a  prototype  system  which  was  demonstrated  to 
the  prospective  end-users.  To  meet  specific  user  requirements,  the  advanced  features  of 
the  development  environment  were  taken  advantage  of. 

The  underlying  structure  of  OMNIS7  eliminated  the  requirement  of  using  common 
fields  to  create  a  link  between  objects.  This  system  is  developed  using  Blythe  Software’s 
OMNIS7  Integrated  Development  Environment,  version  1.03. 
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II.  DEFINITION  PHASE 


The  first  phase  of  an  application  development  is  to  define  what  the  project  will  do. 
The  projCi  t  ivay  be  to  modify  an  existing  application,  develop  a  comprehensive  set  of 
applications  around  a  common  database,  or  automa‘.  a  manual  data  related  task.  The 
definition  can  be  determined  by  a  team  of  experts  working  together  or  through  a  series 
of  interviews  or  a  combination  of  both  of  these.  The  scope  of  the  project  is  determined 
du.'mg  the  dei.nition  phase  (i.e.,  what  will  be  included  as  necessary  functions  as  well  as 
wha.  V  .I’d  be  extraneous  functionality)  The  final  function  of  the  definition  phase  is 
d'MP'i.iang  the  feasibility  of  the  project.  Feasibility  includes  cost,  technical  and 
schedule.  [Ref  3:  pg.  75] 

A.  SCOPE  OF  THE  PROJECT 

The  goal  of  this  project  was  to  automate  and  track  Temporary  Additional  Duty 
orders  and  travel  claims  generation.  A  determination  was  made  that  all  work  could  be 
accomplished  on  a  single  IBM-compatible  386  computer  operating  under  Microsoft 
Windows  using  4mb  RAM.  The  project  was  scheduled  to  run  from  March  92  to  June  92. 
An  extension  until  Seotember  92  was  granted  due  to  the  complexity  of  the  OMNIS7 
Integrated  Development  Environment.  System  functionality  requirements  were  determined 
during  interviews  with  members  of  the  Administrative  Sciences  Department  as  well  as 
those  members  of  the  staff  for  whom  the  application  was  designed. 
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The  requirements  which  were  agreed  upon  included  the  following; 

1.  Microsoft  Windows  based  application  developed  using  the  OMNIS7  Integrated 
Development  Environment 

2.  A  data  structure  was  to  be  developed  which  would  link  the  required  reports  to  the 
personnel  data  file  format. 

3.  The  on-screen  editor  would  resemble  the  actual  form  as  closely  as  possible, 

4.  _.n-screen  editing  and  updating  of  forms  could  be  completed  easily. 
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III.  REQUIREMENTS  PHASE 


The  requirements  phase  is  the  one  during  which  the  determination  is  made  of 
exactly  what  it  is  that  the  system  will  do.  The  goals  of  the  system  are  delineated.  The 
methods  for  determining  the  scope  of  the  user’s  requirements  are  varied.  Interviews  are 
sometimes  ineffective  as  the  users  themselves  do  not  have  the  knowledge  to  put  forth 
pertinent  questions.  In  this  case  it  is  up  to  the  design  team  to  sound  the  users  for 
concepts  of  what  it  is  they  need.  The  design  team  may  use  a  prototype  which  includes 
sample  forms,  reports  and  menus  to  give  the  end  user  an  idea  of  the  capabilities  of  the 
proposed  system.  [Ref.  3:pg  77] 

A.  METHODOLOGY 

Interviews  were  conducted  with  the  members  of  the  Administrative  Sciences 
Department  for  whom  the  application  would  be  developed.  The  administrative  assistant 
described  functional  requirements  in  great  detail.  The  professors  supervising  the 
development  provided  the  information  related  to  the  underlying  data  structure. 

The  process  of  producing  a  prototype  system  from  the  initial  requirements  and  its 
first  version  was  reviewed  by  the  supervising  professor.  Minor  changes  in  the  screen 
displays  were  requested.  This  process  required  just  one  iteration.  The  final  version  was 
delivered  and  deemed  acceptable  both  by  the  end  user  and  the  supervising  professor.  The 
prototype  was  installed,  allowing  enough  time  for  the  developer  to  make  minor  changes 


in  structure  and  report  fornii:i,  \n  in  depth  tutorial  for  the  end  user  was  provided  by  the 
system  developer. 

B.  DATA  REQUIREMENTS 

In  a  relational  database  structure  the  underlying  entity  is  an  object.  In  the  OMNIS7 
Integrated  Development  Environment  the  individual  objects  are  defined  by  file  formats, 
as  shown  in  Tables  1  through  5.  It  was  determined  that  a  total  of  four  file  formats  would 
need  to  be  developed.  The  formats  which  comprise  the  data  structure  of  the  TDS  are 
PERSDATA.DFl,  DD1610.DF1,  NP1320.DF1  and  DD1351.DF1.  The  file  formats  are 
linked  using  the  Record  Sequencing  Number  (RSN)  feature. 

The  PERSDATA.DFl  file  format  is  comprised  of  data  and  object  properties,  which 
comprise  each  personnel  record  in  the  personnel  file.  This  is  the  information  which  is 
required  for  the  personnel  information  portion  of  the  DD  forms  1610  and  1351  as  well 
as  the  NAVPERS  form  1320.  The  PERSDATA.DFl  represents  the  parent  file  format  in 
the  parent-child  file  format  relationship  as  shown  in  Figure  1. 
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Figure  1.  Relational  Diagram 


The  file  format  DD1610.DF1  is  a  child  file  format.  This  format  has  fn  optional 
Mai;j(DD1610)-to-One(PERSDATA)  relationship.  The  file  format  NP1320.DF1  is  also 
a  child  of  PERSDATA  and  shares  the  same  relationship  as  the  DD1610  file  format.  The 
DD1351.DF1  file  format  is  a  child  of  both  the  DD1610  and  the  NP1320  file  formats. 
This  file  format  shares  an  optional  One-to-One  relationship  with  it’s  parent  file  formats. 
See  Figure  2. 


DD 1610 

NAVPERS 1320 

NAME 

POGmOM 

NAME 

OFFXSAL  STATION 

posnoN 

OnOANIZAIIONM.  ELBenr 

OFHCtALtTATION 

PHONE  NUMBER 

ORRMHZATIONAL  BBIBIT 

SeCXJIVrY  CLEARANCE 

PHONE  NUMBER 

- 

— 

DD1351 

Figure  2.  File  Format  Relationship 
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c.  UPDATE,  DISPLAY  AND  CONTROL  MECHANISMS 


In  order  to  complete  the  development  of  a  database  application  the  user-system 
interactions  must  be  delineated.  In  the  case  of  TDS  this  meant  developing  a  plan  for  the 
user  to  make  his/her  way  through  a  series  of  data  display  windows  while  manipulating 
the  required  data.  (See  Data  Flow  Diagrams  depicted  in  Figures  and  4). 


Figure  3.  Context  Level  Dataflow  Diagram 
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member’s  Last  Name.  If  the  member  is  not  in  the  database  the  member  will  be  entered. 
If  the  member  is  in  the  database  the  record  will  be  checked  for  validity  and  updated  if 
required.  If  the  member  is  in  the  Navy  then  the  NAVPERS  1320  window  is  opened  from 
within  the  Personnel  Data  Window.  If  the  member  is  not  in  the  military  the  DD1610 
Window  is  opened  from  within  the  Personnel  Data  Window.  At  this  point  all  the  data 
entry  fields  of  the  forms  pertaining  to  Personnel  Data  are  automatically  filled  in.  The 
Administrative  Assistant  is  then  tasked  with  completing  the  form.  The  completed  form 
is  then  printed  out  and  delivered. 

In  order  to  complete  the  DD  form  1351,  the  user  enters  the  database  through  the 
Personnel  Data  Window,  finds  the  member,  then  opens  either  the  DD  1610  window  or 
the  NAVPERS  1320  window  whichever  is  appropriate.  The  travel  order  which 
corresponds  to  the  requested  DD1351  must  be  displayed  on  the  screen.  The  user  then 
selects  DD  1351  and  the  data  entry  window  is  opened  with  all  previously  entered  data 
automatically  displayed.  The  administrative  assistant  then  enters  the  remaining  data, 
prints  the  report,  and  submits  it  to  the  appropriate  office. 

The  diagram  depicted  in  Figure  5  is  a  representation  of  the  menu  hierarchy.  In  this 
database  application  the  menu  hierarchy  is  a  direct  representation  of  the  underlying  data 
structure. 
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Figure  5.  Menu  Hierarchy 


DATA  DICTIONARY 
TABLE  1.  DATA  FILES 


FILE  NAME 

TYPE 

DESCRIPTION 

PERSDATA.DFl 

DATA 

ATTRIBUTES  OF  PERSONNEL  DATA  FILE 

DD1610.DF1  • 

DATA 

ATTRIBUTES  OF  DD  1610 

NP1320.DF1 

DATA 

ATTRIBUTES  OF  NAVPERS  1320\B 

DD1351.DF1 

DATA 

ATTRIBUTES  OF  DD  1351 
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TABLE  2.  FILE  FORMAT  PERSDATA.DFl 


Element 

-Type _ 

Width 

Descriotion 

LAST_NAME 

Character 

15  IND 

last  name 

FIRST_NAME 

Character 

15  IND 

first  name 

MIDDLE_INITIAL 

Character 

1 

middle  initial 

POSITION 

Character 

35 

SSN 

Character 

11  IND 

PHONE_NUMBER 

Character 

13 

DEPARTMENT 

Character 

15 

CLEARANCE 

Character 

15 

Security  clearance 

OFF_STA 

Character 

30 

Official  Station 

ORG_ELE 

Character 

30 

Organizational  Element 

TYPE_TRAVELER 

Character 

10 

DESIGNATOR 

Character 

4 

STREET_ADDRESS 

Character 

30 

CITY 

Character 

10 

STATE 

Character 

2 

ZIP_CODE 

Character 

5 

RANK_1 

Character 

6 

SERVICE_1 

Character 

6 

Record  length  is  between  26  and  338  bytes 

1000  records  may  use  between  141000  and  615000  disk  bytes 
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TABLE  3.  FILE  FORMAT  DD1610.DF1 


Element 

_ Type _ 

Width 

Description 

REQUEST_DATE 

Date 

D  m  Y 

Block  1 

PROCEED_DATE 

Date 

D  m  Y 

Block  10b 

PURPOSE 

Character 

280 

Block  9 

ITINERARY 

Character 

42 

Block  11 

RETURN_DATE 

Date 

D  m  Y 

Included  in  Block  11 

APPOX_DAYS 

Character 

10 

Block  10a 

TyPE_ORDERS 

Character 

5 

Block  7 

VAR_AUTH 

Character 

1 

Included  in 

Block  11 

Variation  Authorized 

COM_RAIL 

Character 

1 

Block  12 

Commercial  Rail 

C0M_A1R 

Character 

1 

Block  12 

Commercial  Air 

COM_BUS 

Character 

1 

Block  12 

Commercial  Bus 

COM_SHIP 

Character 

1 

Block  12 

Commercial  Ship 

GOV  AIR 

Character 

1 

Block  12 

Government  Air 
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TABLE  3,  cont. 

GOV  VEH 


GOV  SHIP 


RATE  PER  MILE 


ADV  GOVT 


REIMBURS 


PER  DIEM  AUTH 


OTHER  PER  DIEM 


AS  DET 


EST  PER  DIEM 


EST  TRV  COST 


EST  OTHER 


EST  TOTAL 


ADV  AUTHORIZED 


REMARKS 


Character  1 

Character  1 

Number  2  dp 

Character  1 

Character  1 

Character  1 

Character  1 

Character  1 


Number  2  dp 

Number  2  dp 

Number  2  dp 

Number  2  dp 

Character  5 

Character  420 


Block  12 

Government  Vehicle 
Block  12 
Government  Ship 
Block  12 
Rate  Per  Mile 
Block  12 
Advantage  Gov't 
Block  12 
Reimbursement 
Block  13 

Per  Diem  Authorized 
Block  13 

Other  Per  Diem  Rate 
Block  12 
Overseas  travel 
only 
Block  14 

Estimated  Per  Diem 
Block  14 

Est.  Travel  Cost 
Block  14 
Other  Expenses 
Block  14 
Estimated  Total 
Block  14 

Advance  Authorized 
Block  16 
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TABLE  3,  cont 


i^EQ  OFF 

Character 

30 

Block  17 

Requesting  Officia 

APP_OFF 

Character 

30 

Block  17 

Approving  Official 

APP_SUB_1 

Character 

16 

Block  19 

APP_SUB_2 

Character 

16 

Appropriation 

APP_SUB_3 

Character 

16 

and  Subhead 

OBJ_CLASS_l 

Character 

4 

Block  19 

OBJ_CLASS_2 

Character 

4 

Object  Class 

OBJ_CLASS_3 

Character 

4 

BUNO_l 

Character 

6 

Block  19 

BUNO_2 

Character 

6 

Bureau  Control 

BUNO_3 

Character 

6 

Number 

SUB_AUTH_1 

Character 

3 

Block  19 

SUB_AUTH_2 

Character 

3 

Sub-auth 

SUB_AUTH_3 

Character 

3 

AUTH_ACCT_1 

Character 

8 

Block  19 

AUTH_ACCT_2 

Character 

8 

Authorizing 

AUTH_ACCT_3 

Character 

8 

Acct.  Activity 

TYPE_1 

Character 

4 

Block  19 

TYPE_2 

Character 

4 

Type 

TYPE_3 

Character 

4 

16 


TABLE  3,  cont 


TANGO_NO_l 

Character 

6 

Block  19 

TANGO_NO_2 

Character 

6 

Travel  Order 

TANGO_NO_3 

Character 

6 

Number 

COST_CODE_l 

Character 

15 

Block  19 

COST_CODE_2 

Character 

15 

Cost  Code 

COST_CODE_3 

Character 

15 

ORD  AUTH  OFF 

Character 

15 

Block  20 

Order 

Authorizing 

Official 


ISSUE_DATE  Date  D  m  Y  Block  21 

Date  Issued 


TRAVEL  ORD  NO  Character 


20  IND  Block  22 

Travel  Order 
Number 


Record  length  is  between  136  and  1720  bytes 

1000  records  may  use  between  226000  and  2527000  disk  bytes 
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TABLE  4.  FILE  FORMAT  NP1320.DF1 


element  _ Type _ Width _ Description 


FR0M_1 

Character 

60 

Block  1 

STAN_DOC_NO 

Character 

12  IND 

Block  2 

Standard 
Document  Number 

TANGO_NO 

Character 

12 

Block  4 

DATE 

Date 

D  m 

Block  6 

REF_A 

Character 

40 

BLOCK  7 

INDIVIDUAL 

Character 

1 

BLOCK  8 

Individual 

Travel 

GROUP 

Character 

1 

BLOCK  8 

Group  Travel 

PROCEED_ON 

Date 

D  m  Y 

Block  9 

AUTH_PROCEED 

Date 

D  m  Y 

Block  10 

APPROX_DAYS 

Character 

10 

Block  11 

EST_RETURN_DATE 

Date 

D  m  Y 

BLOCK  12 

ITINERARY 

Character 

240 

Block  13 

TEMADD 

Character 

1 

BLOCK  14 

TEMADD 

TEMADDCON 

Character 

1 

BLOCK  14 
TEMADDCON 

TEMADDINS 

Character 

1 

Block  14 
TEMADDINS 

REASON 

Character 

120 

BLOCK  15 

AUTH_VISIT 

Character 

1 

Block  16 

APP_SYM_1 

Character 

7 

Block  17 

18 


TABLE  4,  com 


APP_SYM_2 

Character 

7 

Appropriation 

APP_SYM_3 

Character 

7 

symbol 

SUB_HEAD_1 

Character 

4 

Block  17 

SUB_HEAB_2 

Character 

4 

Appropriation 

SUB_HEAD_3 

Character 

4 

Subhead 

OBJECT_l 

Character 

3 

Block  17 

OBJECT_2 

Character 

3 

Object  Class 

OBJECT_3 

Character 

3 

BU_CONT_l 

Character 

4 

Block  17 

BU_CONT_2 

Character 

4 

BU  CONT  NUMBER 

BU_CONT_3 

Character 

4 

SUB_ALLOT_l 

Character 

5 

Block  17 

SUB_ALLOT_2 

Character 

5 

Sub-Allot 

SUB_ALLOT_3 

Character 

5 

Number 

AUTH_ACC'rG_l 

Character 

6 

Block  17 

AUTH_ACCTG_2 

Character 

6 

Authorized 

AUTH  ACCTG  3 

Character 

6 

ACCTG 

Activity 

TY_1 

Character 

2 

Block  17 

TY_2 

Character 

2 

TYPE 

TY_3 

Character 

2 

ACCTG_ACTY_1 

Character 

6 

Block  17 
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TABLE  4,  cont. 


ACCTG_ACTy_2 

Character 

6 

PROPERTY 

ACCTGACTY 

ACCTG_ACTY_3 

Character 

6 

CC_1 

Character 

22 

Block  17 

CC_2 

Character 

12 

Cost  Code 

CC_3 

Character 

12 

TRANSPORTATION 

Number 

2  dp 

Block  18 
Transportation 

PERDIEM 

Number 

2  dp 

Block  18 

Per  Diem 

MISC_EXP 

Number 

2  dp 

Block  18 

Misc.  Exp 

TOTAL_EXP 

Number 

2  dp 

Block  18 

Total 

CUST_ID_CODE 

Character 

18 

Block  19 

ITEM 

Character 

120 

Block  20 

COMMENTS 

Character 

400 

Block  21 

AUTH_SIG 

Character 

40 

Block  23 

TRANS_REQUEST 

Character 

240 

Block  24 

COPY_TO 

Character 

40 

Block  25 

Record  length  is  between  122  and  1780  bytes 

1000  records  may  use  between  199000  and  2598000  disk  bytes 
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TABLE  5.  HLE  FORMAT  DD1351.DF1 


Element _ Typ.e _ V7idth  nescription 


PRIOR  PAY 


Character  40  Prior  travel 

payments  or 
advances  under  these 
orders 


DEP  1 

Date 

D 

m 

Y  Block  1:  Dates 

ARR  1 

Date 

D 

m 

Y 

DEP  2 

Date 

D 

m 

Y 

ARR  2 

Date 

D 

m 

Y 

DEP  3 

Date 

D 

m 

Y 

ARR  3 

Date 

D 

m 

Y 

DEP  4 

Date 

D 

m 

Y 

ARR  4 

Date 

D 

m 

Y 

DEP  5 

Date 

D 

m 

Y 

ARR  5 

Date 

D 

m 

Y 

DEP  6 

Date 

D  m 

Y 

ARR  6 

Date 

D  m 

Y 

DEP  7 

Date 

D  m 

Y 

ARR_7 

Date 

D  m 

Y 

TIME  1 

Short  time 

Block 

1: 

Times 

TIME  2 

Short  time 

TIME  3 

Short  time 

TIME  4 

Short  time 

TIME  5 

Short  time 

TIME  6 

Short  time 

TIME  7 

Short  time 

TIME  8 

Short  time 

TIME  9 

Short  time 

TIME  10 

Short  time 

TIME  11 

Short  time 

TIME  12 

Short  time 

TIME  13 

Short  time 

TIME_14 

Short  time 

PLACE  1 

Character 

15 

Block 

1: 

Place 

PLACE  2 

Character 

15 

PLACE  3 

Character 

15 

PLACE  4 

Character 

15 

PLACE  5 

Character 

15 

PLACE  6 

Character 

15 

PLACE  7 

Character 

15 

PLACE  8 

Character 

15 
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LE  5,  cont. 

MODE_l 

Character 

2 

Block  1:  Mode  of 

MODE  2 

Character 

2 

travel 

MODE  3 

Character 

2 

MODE  4 

Character 

2 

MODE  5 

Character 

2 

MODE  6 

Character 

2 

MODE  7 

Character 

2 

STOP_i 

Character 

2 

Block  1:  Reason 

STOP  2 

Character 

2 

for  stop 

STOP  3 

Character 

2 

STOP  4 

Character 

2 

STOP  5 

Character 

2 

STOP  6 

Character 

2 

STOP_7 

Character 

2 

COL_l 

Number 

2  dp 

Block  2:  Cost  of 

COL  2 

Number 

2  dp 

lodging 

COL  3 

Number 

2  dp 

COL  4 

Number 

2  dp 

COL  5 

Number 

2  dp 

COL  6 

Number 

2  dp 

COL_7 

Number 

2  dp 

MEALS_G_1 

Integer 

(0  to 

255)  Block  3: 

MEALS  G  2 

Integer 

(0  to 

Meals\Govt 

255) 

MEALS  G  3 

Integer 

(0  to 

255) 

MEALS  G  4 

Integer 

(0  to 

255) 

MEALS  G  5 

Integer 

(0  to 

255) 

MEALS  G  6 

Integer 

(0  to 

255) 

MEALS_G_7 

Integer 

(0  to 

255) 

MEALS_D_1 

Integer 

(0  to 

255)  Block  3: 

MEALS  D  2 

Integer 

(0  to 

Meals\Ded 

255) 

MEALS  D  3 

Integer 

(0  to 

255) 

MEALS  D  4 

Integer 

(0  to 

255) 

MEALS  D  5 

Integer 

(0  to 

255) 

MEALS  D  6 

Integer 

(0  to 

255) 

MEALS_D_7 

Integer 

(0  to 

255) 

OM_l 

Integer 

(0  to 

255)  Block  3:  Open 

OM  2 

Integer 

(0  to 

Mess 

255) 

OM_3 

Integer 

(0  to 

255) 

22 


table  5,  cont. 

OM_4 

OM_5 

OM_6 

OM_7 

P0C_MILES_1 

P0C_MILES_2 

P0C_MILES_3 

P0C_MILES_4 

POC_MILES_5 

P0C_MILES_6 

POC_MILES_7 

DATE_1 

DATE_2 

DATE_3 

DATE_4 

N_E_1 

N_E_2 

N_E_3 

N_E_4 

amt_claim_i 

AMT_CLAIM_2 

AMT_CLAIM_3 

AMT_CLAIM_4 

ALLOWED_l 

ALL0WED_2 

ALL0WED_3 

ALL0WED_4 


appr  officer 


number_i 

NUMBER_2 

FROMl 

FROM2 

TOl 

T02 


Integer 

integer 

Integer 

Integer 

Number 

Number 

Number 


(0  to  255) 

(0  to  255) 

(0  to  255) 

(0  to  255) 

0  dp  Block 
0  dp 
0  dp 


4:  pOC  Miles 


Number 

Number 

Number 

Number 

Date 

Date 

Date 

Date 

Character 

Character 

Character 

Character 

Number 

Number 

Number 

Number 

Number 

Number 

Number 

Number 


Character 


Character 

Character 

Character 

Character 

Character 

Character 


0  dp 

0  dp 

0  dp 

0  dp 

D  m  Y 

D  m  Y 

D  m  Y 

D  m  Y 

Block  5:  Date 

20 

20 

20 

20 

Block  5;  Naure  & 

Explanation 

2  dp 

2  dp 

2  dp 

2  dp 

Block  5:  Amt. 
Claimed 

2  dp 

2  dp 

2  dp 

2  dp 

Block  5:  Allowed 

15 

Block  6:  Approving 
Officer 

20 

20 

Block  7:  Nximber 

20 

20 

Block  7:  From 

20 

20 

Block  7:  To 
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TABLE  5,  cont 


LEAVE 

Integer 

0 

to  255 

Block  8:  Leave 
days 

HOURS 

Integer 

0 

to  255 

Block  8 :  Leave 
hours 

DATE_8 

Date 

D 

m  Y 

Block  8:  Start 
date 

DATE_9 

Date 

D 

m  Y 

Block  8:  End 
date 

POC_OWNER 

Character 

1 

Block  9 :  POC 
Owner 

POC_PASS 

Character 

1 

Block  9; 
Passenger 

CHECK 

Character 

1 

Block  11:  Check 

CASH 

Character 

1 

Block  11:  Cash 

PER_DIEM_REQ 

Character 

1 

Block  12:  Per 
Diem  Requested 

Record  length  is  between  436  and  966  bytes. 

1000  records  may  use  between  518000  and  1408000  disk  bytes. 
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IV.  EVALUATION  PHASE 


The  evaluation  phase  actually  consists  of  three  tasks,  all  focused  on  redefining  the 
scope  and  feasibility  of  the  entire  project.  The  first  phase  is  determining  alternatives  to 
the  proposed  solution.  Secondly  the  feasibility  of  the  project  is  re-evaluated  based  on  the 
more  detailed  specifications  which  are  now  available  to  the  designers.  Finally  all  user 
requirements  are  evaluated  within  the  scope  of  the  alternative  solutions.  [Ref.  3:pg.  78] 
The  evaluation  phase  will  be  effective  only  if  a  thorough  understanding  of  the 
system  requirements  is  achieved  during  the  earlier  phases  of  development.  It  was  decided 
early  on  that  using  the  OMNIS7  Integrated  Development  Environment  would  provide  for 
the  development  of  a  graphical  user  interface  which  would  facilitate  learning  by  end 
users.  The  hardware  requirements  were  determined  to  be  of  minimal  concern  as  there  is 
an  ample  supply  of  personal  computers  within  the  Administrative  Sciences  Department. 

It  was  decided  that  the  choice  of  printer  would  be  delayed  until  the  TDS  prototype 
was  installed.  This  would  allow  the  developer  to  evaluate  the  printers  available  in  the 
Administrative  Sciences  Department  and  select  the  one  best  suited  for  the  application. 

The  application  is  designed  using  a  structured  approach.  The  only  possible  obstacle 
foreseen  was  the  process  of  learning  how  to  manipulate  a  very  powerful  database 
development  environment.  Otherwise  it  was  still  well  within  the  realm  of  possibility  for 
this  project  to  be  completed  within  the  expanded  time  constraints. 
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development  environment.  Otherwise  it  was  still  well  within  the  realm  of  possibility  for 
this  project  to  be  completed  within  the  expanded  time  constraints. 
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V,  DESIGN  PHASE 


The  objective  of  the  design  phase  is  to  develop  a  blueprint  for  the  database  and  its 
associated  applications.  During  this  phase  the  development  team  establishes  the  database 
schema,  the  application  sub-schema,  formats  for  forms,  reports,  menus  as  well  as  the 
underlying  logic.  The  mechanisms  for  update  display  and  control  are  also  determined  at 
this  time.  After  the  database  has  been  designed  the  team  can  design  each  application 
which  consists  of  a  collection  of  menus,  forms  reports  and  programs  which  meet  the 
specific  user  needs.  [Ref.  3:pg.  79] 

A,  NORMALIZATION 

The  goal  of  a  logical  database  is  to  represent  objects  in  the  database  using  relations. 
The  construction  of  user  objects  so  that  rows  of  data  can  be  inserted,  deleted,  and 
modified  without  resulting  inconsistencies  or  errors  is  paramount.  The  deletion  anomaly 
occurs  when  one  object  is  deleted  and  has  the  effect  of  deleting  data  from  another  object 
instance.  The  insertion  anomaly  occurs  when  data  cannot  be  inserted  into  one  entity  until 
data  is  known  about  another  entity.  These  conditions  can  cause  serious  problems  in 
database  design.  The  current  design  has  all  its  relationships  ,  as  defined  in  Tables  1  -  5, 
in  Boyce-Codd  Normal  Form. 
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B.  PHYSICAL  DATABASE  DESIGN 


The  four  file  formats  involved  in  the  Travel  Database  system  are  delineated  in 
Tables  1  through  5.  The  key  attributes  (SSN,  TRAVEL_ORD_NO,  and 
STAN_DOC_NO)  are  noted  with  an  asterisk.  Their  relationship  to  one  another  is 
graphically  represented  in  Figure  2.  In  the  OMNIS7  environment  the  unique  key  attribute 
is  used  to  functionally  define  each  relation,  in  other  words,  the  remaining  attributes  of 
an  object  are  associated  in  that  file  format  to  that  unique  key.  As  an  illustration,  only  one 
record  may  have  a  particular  SSN  in  the  PERSDATA  file.  Likewise  only  one  travel 
order  may  be  linked  to  a  unique  Travel  Order  Number,  although  several  travel  orders 
may  belong  to  one  SSN.  The  relations  are  linked  using  OMNIS7’s  record  sequencing 
number  (RSN)  feature. 

The  RSN  feature  takes  care  of  the  requirement  to  carefully  arrange  relational  joins 
to  avoid  anomalies.  For  instance,  if  a  personnel  record  is  deleted,  all  of  that  person’s 
travel  orders  and  travel  claims  are  still  available.  Likewise,  a  travel  claim  or  travel  order 
can  be  deleted  without  affecting  the  associated  personnel  record. 
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VI.  IMPLEMENTATION  PHASE 


The  final  phase  of  the  process  is  implementation.  The  details  of  the  implementation 
depend  a  great  deal  on  the  DBMS  being  used.  OMN1S7  is  a  very  powerful  program  and 
nearly  all  of  the  requirements  could  be  generated  by  the  automatic  code  generation 
features  of  the  development  environment.  This  feature  reduced  the  amount  of  effort 
required  in  the  initial  phase  of  implementation.  Testing  and  installation  are  the  final  two 
stages  of  the  implementation  phase.  [Ref.  3:pg  81] 

A.  PROGRAMMING 

The  goal  of  this  phase  is  to  construct  the  system  as  designed.  The  powerful  nature 
of  the  OMNIS7  Development  Environment  did  not  require  a  great  deal  of  custom  coding 
(creating  procedures  in  OMNIS7  parlance).  Those  custom  procedures  which  were  coded 
are  included  in  Tables  6  through  9.  The  majority  of  the  code  is  generated  automatically 
by  OMNIS7  and  is  therefore  transparent  to  the  developer.  Procedures  can  be  initiated  fo’* 
any  field  on  any  window  or  custom  pushbuttons  can  be  generated.  The  code  written  for 
this  application  facilitated  report  printing. 
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TABLE  6.  CUSTOM  PROCEDURES  -  PERSONEL  WINDOW,  W  PERS  DATA 
0.  Initial  Control  Procedure 

Set  Main  File  {FPERS  DATA} 

Prepare  for  insert 


24.  DD  1610  (pushbutton) 

Open  window  W_DD1610 

25.  NAVPERS  1320  (pushbutton) 

Open  window  NAVPERS  1320 

TABLE  7.  CUSTOM  PROCEDURES  -  NAVPERS  1320  WINDOW, 
NAVPERS  1320 

66.  PRINT  NAVPERS  1320  (pushbutton) 

Set  report  name  RD_NAVPERS  1320 

YES/NO  message  (Large  size)  {Print  Standard  Document  Number 
[STAN_DOC_NO]  for  [FIRST_NAME]  [LAST_NAME]  ?} 

If  flag  true 

Prepare  for  print 
Print  record 
Print  totals 
End  if 
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67.  DD  1351  (pushbutton) 

Open  window  W_DD1351 

TABLE  8.  CUSTOM  PROCEDURES  -  DD  1610,  W_DD1610 

72.  PRINT  DD  1610  (pushbutton) 

Set  report  name  DD_1610 

YES/NO  message  (Large  size)  {Print  Travel  Order  Number 
[TRAVEL_ORD_NO]  for  [FIRST_NAME]  [LAST_NAME]  ?} 

If  flag  true 

Prepare  for  print 
Print  record 
Print  totals 
End  if 

73.  DD  1351  (pushbutton) 

Open  window  W_DD1351 
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TABLE  9.  CUSTOM  PROCEDURES  -  DD  1351,  W  DD1351 
72.  PRINT  DD  1351  (pushbutton) 


Set  report  name  DD_1351 

YES/NO  message  (Large  size)  (Print  DD  1351  for  [FIRST_NAME] 
[LAST_NAME]  ?} 

If  flag  true 

Prepare  for  print 
Print  record 
Print  totals 
End  if 


B.  TESTING  AND  INSTALLATION 

The  TDS  was  tested  as  a  complete  unit,  although  it  consists  of  three  separate 
modules.  The  system  was  installed  on  an  Administrative  Sciences  Department  PC  and 
test  data  was  entered.  Some  format  errors  were  discovered  on  the  data  input  screens, 
which  were  corrected  immediately.  Some  errors  were  also  found  in  connection  with 
report  output.  Upon  careful  examination  of  these  errors  it  was  concluded  that  the  existing 
printer  could  not  support  the  application.  A  new  printer  was  therefore  procured  and  all 
errors  were  subsequently  eradicated  from  the  system. 
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VII.  CONCLUSION 


The  Travel  Database  System  is  currently  installed  in  the  Administrative  Sciences 
Department  Support  Staff  Office  and  is  running  in  accordance  with  the  design 
specifications.  The  users  have  indicated  satisfaction  with  the  system  although  it  is  not 
being  used  to  the  fullest.  The  result  of  maximizing  the  use  of  this  system  would 
undoubtedly  be  an  increased  productivity  and  a  more  uniform  output  from  the  office. 

The  integration  of  an  accounting  system  with  TDS  would  further  tl.e  department’s 
dependency  upon  these  applications.  This  would  improve  user  acceptance  of  the  computer 
in  the  work  space.  The  generation  of  future  applications  using  OMNIS7  is  highly 
recommended.: 

Future  upgrades  to  the  existing  system  can  be  readily  determined  as  well.  A  series 
of  reports  highlighting  accounting  data  and  travel  as  well  as  further  automation  of  data 
retrieval  are  just  two  examples. 


APPENDIX  A. 

USER’S  GUIDE  TO  THE  ADMINISTRATIVE  SCIENCE  DEPARTMENT’S 

TEMADD  DATABASE  SYSTEM 


A.  INTRODUCTION 

The  purpose  of  this  manual  is  to  familiarize  the  user  with  the  Administrative 
Sciences  Department’s  TEMADD  Database  System  (TDS).  The  system  is  linked  through 
a  series  of  windows  or,  for  more  experienced  users,  a  series  of  pull  down  menus.  The 
system  is  designed  to  be  easy  to  use  but  does  require  some  familiarity  with  Microsoft 
Windows  and  the  use  of  a  mouse. 

B.  GETTING  STARTED 

Before  running  TDS,  the  OMNIS7  Integrated  Development  Environment  and 
Microsoft  Windows  must  be  installed  as  specified  in  their  respective  user’s  manuals.  The 
application  file  TRAVEL.  APP  must  be  loaded  onto  the  hard  drive.  The  hard  disk  storage 
space  required  is  4  MB.  The  data  files  can  be  maintained  on  a  floppy.  To  run  the 
application  from  the  prototype  software  the  user  must  first  initialize  Microsoft  Windows. 
The  following  steps  will  guide  the  user  to  the  PERSONNEL  window. 

1.  From  PROGRAM  MANAGER  select  the  OMNIS7  Icon  and  initialize  the 
OMNIS7  Integrated  Development  Environment. 

2.  From  OMNIS7  Bar  Menu  select  RLE.  Select  OPEN  APPLICATION  from  the 
pull  down  menu.  See  Figure  A-1. 
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3.  Highlight  TRAVEL. APP  from  the  pop-up  menu  and  press  <  enter  > .  See  Figure 
A-2. 


I.rirri  nnplirrttinn 


Figure  A-2.  Select  Application  Pop-Up  Menu 


4.  Select  DESIGN  from  the  OMNIS7  bar  menu.  Next,  select  MENU  FORMATS 
from  the  pull  down  menu.  See  Figure  A-3. 


5.  Highlight  TRAVEL  from  the  pop-up  menu  and  Select  the  INSTALL  option  from 
the  buttons  on  the  right  hand  side  of  the  pop-up  menu.  See  Figure  A-4. 


Figure  A-4.  Menu  Formats  Pop-Up  Menu 


6.  The  TRAVEL  menu  will  now  be  installed  in  the  bar  menu. 

7.  Highlight  the  TRAVEL  selection  from  the  bar  menu.  The  PERSONNEL  option 
will  be  highlighted.  See  Figure  A-5. 


8.  Press  ENTER.  The  PERSON"NEL  entry  form  will  come  up  on  the  screen.  See 
Figure  6.  The  TDS  is  now  ready  fo’'  data  entry. 
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Figure  A-6.  Personnel  Data  Entry  Window 
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C.  PUSH  BUTTONS 


There  are  five  push  buttons  common  to  all  four  data  entry  windows,  the 
pushbuttons  which  are  unique  will  be  described  in  the  data  entry  portion. 


1 .  FIND.  The  FIND  button  will  initialize  a  search  on  the  file  until  the  designated 
record  is  found.  If  the  record  is  not  found  the  user  is  told  that  no  match  exists. 
To  use  this  feature  place  the  mouse  over  the  blue  FIND  button  and  depress  the 
left  mouse  button.  The  cursor  will  be  automatically  in  the  data  entry  field  against 
which  the  search  will  be  conducted.  Enter  the  value  (name,  travel  order  number, 
etc.)  which  is  the  unique  value  of  the  record  you  wish  to  find  and  press  ENTER 
or  press  the  OK  push  button.  If  the  record  exists  it  will  be  displayed.  If  you  are 
told  that  the  record  does  not  exist,  check  the  entry  and  try  again. 

2.  EDIT.  The  EDIT  pushbutton  will  prepare  the  record  which  is  currently  displayed 
for  editing.  The  cursor  will  tab  between  fields,  highlighting  the  active  field.  The 
user  may  also  highlight  the  field  by  placing  the  mouse  arrow  directly  on  the  field 
which  is  to  be  edited  and  pressing  the  left  button.  When  the  desired  field  is 
highlighted  the  editing  may  be  completed.  Once  all  of  the  desired  fields  are 
edited,  the  user  must  press  the  OK  button. 

3.  INSERT.  The  INSERT  pushbutton  places  the  cursor  in  the  first  field  into  which 
data  may  be  entered.  Once  a  record  is  completed  the  user  must  press  ENTER  or 
OK. 

4.  OK  and  CANCEL.  These  pushbuttons  are  active  during  the  EDIT  and  INSERT 
operations  and  are  used  to  end  the  process.  OK  allows  the  data  to  be  written  to 
the  file.  CANCEL  simply  ends  the  data  entry  process  without  writing  to  the  data 
file. 


D.  PERSONNEL  DATA  FORM 
1.  Data  Entry 


1 .  Move  the  mouse  over  the  INSERT  pushbutton.  After  the  button  has  been  pressed 
the  cursor  will  be  in  the  LAST  NAME  data  entry  field. 


41 


2.  Enter  the  required  data  and  <  TAB>  to  the  next  field.  Once  all  the  required  data 
is  entered  press  the  OK  button  in  the  same  fashion  described  in  step  one. 

3.  To  insert  another  record  repeat  step  one. 

2.  Find\View\Edit  Record 


1 .  Position  the  mouse  over  the  find  button  and  depress  the  left  mouse  button. 

2.  The  cursor  will  automatically  move  to  the  LAST  NAME  field. 

3.  At  this  point,  if  the  last  name  is  known,  enter  it  and  press  <  ENTER  >.  The 
desired  record  will  appear  in  the  data  entry  form. 

4.  If  the  last  name  is  unknown,  enter  the  first  initial  of  the  last  name  and  press 
<ENTER>. 

a.  At  this  point,  the  first  record  beginning  with  the  desired  letter  will  appear. 
To  scroll  through  the  records  position  the  mouse  over  the  NEXT 
pushbutton  and  click  with  the  left  mouse  button.  Each  click  will  put  the 
next  record  into  the  data  entry  window.  Continue  clicking  until  the  desired 
record  is  found. 

5.  To  EDIT  the  record  simply  position  the  mouse  over  the  EDIT  pushbutton  and 
depress  the  left  mouse  button.  The  first  data  entry  field  will  be  highlighted.  To 
move  from  field  to  field  press  <TAB> . 

6.  Edit  fields  as  desired.  When  the  editing  is  complete  position  the  mouse  over  the 
OK  pushbutton  and  depress  the  left  mouse  button,  or  press  <  ENTER > . 

3.  Delete  Record 


1.  Find  the  Personnel  Record  which  is  to  be  deleted. 

2.  Position  the  mouse  over  the  COMMANDS  selection  from  the  bar  menu. 

3.  Highlight  DELETE. 
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4.  A  confirmation  window  will  pop-up  in  the  bottom  left  hand  comer  of  the  screen. 
If  the  record  is  to  be  deleted,  select  "YES."  If  a  different  record  is  to  be  deleted, 
select  "NO"  and  find  the  proper  record. 

5.  This  option  will  permanently  remove  the  selected  record  from  the  data  base.  It 
is  recommended  that  extreme  caution  be  used  when  exercising  this  option. 

4.  DD  1610  Data  Entry  Form 

a.  Data  Entry 


1.  InitiJite  the  DD  1610  Data  Entry  form  the  Personnel  Data  entry  Form.  The 
method  for  doing  this  is  as  follows; 

a.  Once  the  desired  Personnel  Record  has  been  entered  or  found  position  the 
mouse  over  the  DD  1610  pushbutton  and  depress  the  left  mouse  button.  The 
DD  1610  Data  Entry  Form  will  come  up  on  the  screen  with  the  personnel 
data  fields  already  filled. 

2.  In  order  to  initiate  a  new  DD  1610,  position  the  mouse  over  the  INSERT 
pushbutton  and  depress  the  left  mouse  button.  The  database  is  now  ready  to 
accept  a  new  record. 

3.  The  cursor  will  be  positioned  in  the  TYPE  ORDER  data  entry  field.  As  the  data 
is  entered,  tab  from  field  to  field. 

4.  When  all  the  required  data  is  filled  in  press  <  ENTER  >  or  position  the  mouse 
over  the  OK  pushbutton  and  depress  the  left  button. 


b.  Find\  View\EdU  Record 


1.  In  order  to  find  a  DD  1610  for  viewing  or  editing  position  the  mouse  over  the 
FIND  button  and  depress  the  left  mouse  button. 

2.  The  cursor  will  be  positioned  in  the  TRAVEL  ORDER  NUMBER  field.  Enter 
the  travel  order  number  which  is  associated  with  th;*.  record  to  be  viewed  or 
edited.  Press  <  ENTER >  and  the  desired  record  will  be  brought  to  the  screen. 
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3.  To  EDIT  the  record,  position  the  mouse  over  the  field  to  be  edited  and  depress 
the  left  mouse  mountain.  <TAB>  between  fields  and  complete  the  required 
editing.  When  all  the  editing  is  completed  press  <  ENTER  > . 


c.  Delete  a  Record 


1.  If  a  record  is  to  be  deleted,  it  must  be  brought  into  the  data  entry  form  as 
described  in  the  Find\View\Edit  section.  Delete  as  described  in  the  Personnel 
section. 

2.  Exercise  extreme  caution  when  using  this  option.  The  record  will  be  permanently 
removed  from  the  database  if  the  option  is  completed. 


d.  Print  a  DD 1610 


1.  Complete  the  data  entry  for  the  DD  1610. 

2.  Position  the  mouse  over  the  PRINT  DD  1610  pushbutton.  Depress  the  left  mouse 
button. 

3.  A  confirmation  window  will  appear  asking  the  user  to  confirm  the  name  and 
travel  order  number. 

4.  If  the  information  in  the  confirmation  window  is  correct,  select  YES.  If  not, 
select  NO. 

5.  Once  the  form  has  been  printed,  position  the  transparency  over  the  data  sheet  and 
create  a  copy.  This  is  the  original. 


e.  NAVPERS  1320 

The  procedures  for  manipulating  this  form  are  the  same  as  for  the  DD 


1610. 
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/.  DD 1351 


The  procedures  for  manipulating  this  form  are  the  same  as  for  the  DD 
1610  and  NAVPERS  1320. 
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APPENDIX  B 
REQUIRED  FORMS 


Figure  B-1 
Figure  B-2 
Figure  B-3 


.  ,  ,  ,  DD  form  1610 
.  NAVPERS  1320\16 
.  .  .  .  DD  form  1351 
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REQUEST  AND  AUTHORIZATION  FOR  TOY  TRAVEL  OF  DOD  PERSONNEL 

(Htftrtnct:  Jomt  Travel  Refutations) 

Tfvel  Authorized  u  Indicated  in  Item!  2  ihrouth  21. 


tfOUCST  H>R  OmOAi  TtAVE 


3.  POSITION  TITLE  AND  GRADE  OR  RATING 


MODE  or  TRANSPORTATION 


pptvATCLv  OWNED  coNvcvANce  (Cheek  one) 


vcHiCLC  SMir  jnATc  pen  milc _ 

I  Monc  AOVANTACCOUS  TOCOVCPNMtNT 

aMlWCACC  neiMSUntCMCNT  AND  PER  OICM  LIMITED  TO  CON' 
STRUCTIve  COST  OP  COMMON  CARRIER  TRANSPORTATION  S 
RELATED  PER  DIEM  AS  DCTCRMINCD  IN  /TR  TRAVEL  TIME  LMTrCD 
AS  INOtCATtO  IN  JTR 


n  OIEM  AUTHORIZED  IN  ACCORDANCE  WITH  JTR 

□other  rate  or  per  jiEM(3;pRir// 


t4.  ESTIMATED  COST 


^AT  thb  space  foe  speciai  re^vements,  Wvr.  superior  or  ht-cUss  accommodations,  excess  boffage,  rtgistratfon  fees,  etc. 


17.  REQUESTING  OrriClAL 


le.  APPROVING  OFWiciAi.(Tiile  and  Signature) 


AUTHOttZATION 


OSJCCT  SURCAU  SUS  AUTMORIIATION  TRAVEL  ORDER 

CLASS  CONTROL  AUTM  ACCOUNTRIC  TYPE  (TengO)nO 
NUMSCR  ACnVTTr 


20.  ORDER  AUTHORIZING  orriCiALfH/ir  and  Signature)  OR  authentication 


21  DATE  ISSUED 


22.  TRAVEL  ORDER  NUMBER 


DD.’SST.  1610  %im  eiet-if  SIE'TTOl 


NAVrOVDIPMNT'JMi  1S71 
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TEMPORARY  ADDITIONAL  DUTY  (TEMADD)  TRAVEL  ORDERS 


2.  SlANDARO  DOCUMENT  f*. 


4.  TAH30  NO. 


f  SSN/OESIGNATOR 


6.  DATE 


9  PROCEED  ON  OR  ABOUT  10.  AUTHORIZED  PROCEED  ON  OR  11.  APPROXIMATE  NUMBER  OF  12.  ESTIMATED  DATE  OF  RETURN 

ABOUT  DWS 


13.  ITINBFtARY  fAc0vffy/MCBvrti4S  tna  PtM/pt$c0nn<]ictltd  tM^w}  14.  , — .  i i — . 

j _ I  TEUAiXI  I _ I  TEUAOOCOM  | _ j  TEMAOOM* 

15.  REASON  FOR  TRAVEL: 


□  AimcmZEO  VISIT  SUCH  AOOITIONM. 
PIACSS  AS  MAY  K  NECESSARY 


17, 

FISCAL  DATA  ACCOUNTING  CLASSIFICATKIN 

APPROPRIATION 
SYMBOL  AND  SUB-HEAD 
(1)  (2) 

OBJECT 

CLASS 

(3) 

8U  CONT 
NUMBER 
(4) 

SUBALLOT 

NUMBER 

(S) 

AUTHORIZED 
ACCTG  ACTY 
(6) 

TYPE 

(7) 

PROPERTY 
ACCTTG  ACTY 
(») 

COST  COCE 

W 

<7  SYM)  (4  SYM) 

i 

(3  SYM) 

(5  SYM) 

(1  SYM) 

(6  SYM) 

(2  SYM) 

(6  SYM) 

(12  SYM) 

EST»4ATEO  COST 


19.  CUSTOMER  IDENTIFICATION  CODE 


20.  ITEM  iUst  tppBcttilt  Btm  nnbtrt  m  Btmirti  on  mmf  mO*  al  H*  km) 


HANSPORTATION  PER  DIEM  MISC.  EXP. 

$  $ 


MISC.  EXP. 

$ 


"Rsport  to  a  Distxjrsng  Officer  unlhln  10  Osya  snsr  cotnplslion  o(  travtl  to  Mitls  your  nvsl  txpertost.’ 


21  ADDITIONAL  COMMENTS  AND  INSTRUCTIONS: 


23  AUTHENTICATING  SIGNATURE 


24  TRANSPORTATION  REQUEST, MAC  TRANSPORTATION  AUTHORIZATION  FURNISHED. 


25  COPY  TO  (Includt  OputBng  Budfot  fund  wntgn  m  $1  ctsn) 


NAVPERS  132016  (Rev.  Il-ST)  SN  0106-LFmi3-2082 


Figure  B-2.  NAVPERS  1320/16 
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